Subject: FW: AIW 9 Minutes

From: Paul Brittain <[email-masked]>
Date: Tue, 28 Nov 95 09:57:00 GMT

Apologies to anyone who missed this when I first mailed it 2 weeks ago.  I 
had thought that aiw-dall would get the minutes to everyone, but obviously 
not because Isabelle did not receive them.

Paul.
 ----------
From: aiw-dall
To: pjb
Subject: AIW 9 Minutes
Date: 14 November 1995 06:12

DLSw RIG - Minutes of AIW 9 meeting
===================================

Thank you to everyone who attended this meeting in Raleigh on November 1-2.
Unfortunately, Louise could not make it to this AIW, so I chaired the
meeting. I also volunteered myself to take notes (never having mastered the
art of delegation!), so if you have any queries about or disagreements with
what follows, please get back to me.

We made good progress on the main area of work for V2, namely the
Scalability RIGlet which gave Dave Bryant and Mike Redden+s Multicast
proposal AD.  If work continues on the mailer between AIWs, I can see no
reason why AP should not be achieved at or soon after AIW10 and CP at AIW11
 - what do you all think?

The rest of this mail gives more detailed notes on the RIG sessions.

Paul Brittain.

MIB
 ---

We started with a short status update from Shannon on the MIB work.  It is
largely complete and should, by now, be with the Network Management
directorate for review as the only comments received last week were of a
minor editorial nature.

Connect
 -------

Steve Klein lead the discussion of the clarifications required to RFC 1795
in the light of the interoperability test experience.  These had been posted 

on the mailer prior to the meeting and were mostly agreed after a short
discussion.  The editor (i.e. me!) will put together an addendum to RFC 1795 

containing these clarifications and post it on the mailer once the various
contributions come in.  As there is no mechanism for updating an
informational RFC, we need to discuss how to publish these clarifications,
plus the scalability and other V2 work, at the next AIW.

The details of the clarifications and any actions are as follows:

 -   Checking that the source port of a TCP connection is 2067 is NOT
permitted.  Frank Bordonaro to post suitable text explaining this.

 -   If a DLSw detects an error in an initial cap-ex, the correct action is
to send a -ve response rather than dropping the TCP pipe, which is supposed
to be the responsibility of the receiver of the -ve response (though it
should not do this after a -ve response to a runtime cap-ex).  Note that
(currently) there is no +negotiation+ of cap-ex i.e. the cap-ex is fully
determined by the single message each way and does not require or allow
multiple exchanges like SNA XID negotiation.

     Equally, any DLSw may drop the TCP pipe if it detects protocol
violations.  If a partner does not drop the TCP pipe after an initial cap-ex 

gets a -ve response, this is a protocol violation.

     The RIG agreed that RFC 1795 describes the spirit of the above
correctly, but the text is not very +watertight+.  Proposals are invited on
how to improve the text. In the meantime please do _not_ drop the TCP pipe
in response to the initial cap-ex from a partner DLSw - send a -ve response
instead!

 -   All DLSw implementations must quietly ignore unrecognized CVs in a
cap-ex message.  This is not clear in the RFC.  Paul Brittain to post text
for this clarification.

 -   If any Vendor-specific CVs are included in the cap-ex, they must be
preceded by a Vendor Context CV.  It is not permitted to rely on the Vendor
ID CV earlier in the cap-ex.  Dave Bryant to post text for this
clarification.

 -   The RII bit in the SSP header MAC address must be zero, even if the
original frame included a RIF or if this is a NetBios SSP message.  It is
also recommended that implementations ignore this bit if it is received.
 Steve Klein to post text for this.

 -   The MAC/LLC header in NetBIOS SSP messages must obey the following
format rules:
     -    addresses are non-canonical
     -    src/dest addresses are as per the LLC frame
     -    AC/FC bits may be reset and must be ignored
     -    SSAP, DSAP and command fields are included
     -    RII bit in src address is copied from the LLC frame
     -    the RIF length is not extended to include padding
     -    all RIFs are padded to 18 bytes so that the data is
          in a consistent place.
     Steve Klein to post text for this clarification.

 -   The Vendor ID may be zero, but the vendor Context CV may not (i.e. if
you want to use vendor-specific CVs, you must get an OUI, but otherwise it
is not required).  Steve Klein to post suitable text.

 -   LF bits are to be propagated in a similar manner to bridges.  Paul
Brittain to post suitable text.

 -   The first FCACK is not required to be on a REACH_ACK .  Paul Brittain
to post suitable text.

Interoperability
 ----------------

The interoperability test conducted at Bay Networks a few weeks before the
AIW was well received - thanks for the hard work Allen!  The view at AIW 9
on future interoperability tests was as follows.

 -   It would be best to wait until there is new function to test in
addition to new implementations.
 -   Some interest in testing Ethernet next time
 -   A tentative timescale of 12-14 months time.
 -   No volunteers to act as host yet.
 -   Can we do anything to get wider PR next time around?
 -   Should we approach someone like Tolly to do a test?  This would almost
certainly have wider PR, but the cost is likely to be significant.

Please post you opinions and suggestions to the interoperability mailer on
any of these subjects.

In the meantime, Data Connection is happy to perform remote testing across
the Internet with individual vendors.  If you would like to arrange such a
test, please contact John Palombo ([email-masked]) for further details.

If any other vendors are able to offer a similar test setup, please post the 

contact details to the DLSw mailer.

Scalability
 -----------

The Multicast proposal from Dave Bryant and Mike Redden was generally well
received and was granted AD status at the end of the RIG meeting.  Listed
below are the comments raised in the meeting.  Dave Bryant and Paul Brittain 

will work on updating the proposal to reflect these comments and post it to
the mailer.

For the time being, this proposal will be maintained as a separate document. 

 At or before the next AIW we should decide whether this will persist or
whether we will merge it with RFC 1795 (& corrections) to give a new RFC for 

DLSw V2.

 -   Dave Bryant pointed out that section 9.1, which talks about directed
frames to the NetBios Functional Address, was a brainstorm that should be
deleted.

 -   Text should be added to describe the handling (quiet ignore) of unknown 

CVs in the SSP encapsulation.

 -   The cap-ex CV for Multicast support is present to allow an up-level
DLSw to detect when a partner is also up-level and therefore does not need
to receive CUR_ex messages over the TCP link  that exists between them (and
there must be one or else the cap-ex would not have flowed) because it will
receive the multicast copies.

 -   Support of this enhancement will require that an implementation
supports use of a single full-duplex TCP connection instead of the two
simplex connections used by default in RFC 1795.  This proposal needs to
document how the TCP connections are brought up.  Proposals are invited on
this topic.

 -   The proposal uses UDP to access multicast (and unicast) IP.  There was
a worry that this is imposing a 20-byte overhead that is not required and
that we should be obtaining an IP protocol ID in stead and going direct to
the IP stack.  Frank Bordonaro to post a proposal on this.

 -   This proposal will not specify any form of hierarchical searching
algorithm across server/peer groups.  However, proposals are invited on this 

subject.  The only any-to-any network architecture supported by the proposal 

as it stands is a single flat network.

 -   We should propose a common naming convention for server and peer groups 

(and how to identify the IP addresses they use) that covers a large address
space.  However we should only reserve a subset of this address space in RFC 

1700 so as not to be too greedy for multicast IP addresses.

 -   This proposal does not address use of IPv6.  This was considered too
far away from widespread availability.

 -   CUR_ex, ICR_ex, NQ_ex and NR_ex messages may be sent over a TCP
connection to an up-level partner if such a connection already exists in
order that they take advantage of the guaranteed delivery of TCP.  This is
particularly recommended for ICR_ex and NR_ex frames where the guaranteed
delivery avoids the need to send unicast retries for these +responses+.

     Note that it is an absolute requirement that all V2 DLSw
implementations support multicast.  It is not permitted to send CUR_ex and
ICR_ex over TCP pipes as part of normal operation as this is precisely the
scalability issue we are trying to solve.  However, it may be useful to, for 

exampe, validate a cache entry using an existing TCP pipe instead of a
general multicast CUR_ex.

 -   NetBios Status Query frames may need to be multicast over the WAN even
if they are not ARB on the source LAN.

 -   The length in the SSP frame encapsulation formats is the length of the
header not the frame.  The frame length can be obtained from IP.

 -   The multicast frame header has the following format:
     -    1 byte header length
     -    1 byte version number
     -    4 bytes source IP address
     -    4 bytes multicast source address.

     The last field may be dropped in future discussions, but was retained
for now to allow greater flexibility.  If it can be removed, that would have 

the benefit of giving the same header format as unicast frames.

 -   The unicast frame header is similar to the multicast frame header but
without the multicast source address.

 -   Further investigation is required to see if additional NetBios frames
can usefully be routed using the multicast/unicast mechanisms in place of
TCP over and above the frames that already have special handling in RFC
1795.  The proposal currently mentions this as a possibility for
STATUS_QUERY.  It has yet to be determined whether new SSP frame types are
required for this or whether implementations are content to parse the
content of datagrams (they may well be doing this already).

AIW 10
======

We have asked for 8-10 hours time at the next AIW (March 25-28, San Jose
Hilton) preferably concentrated in 2-3 days.  The bulk of this time is
intended for Scalability.

One area that was not discussed at AIW 9 was alternate transports.
 Proposals are invited on this topic for discussion at AIW 10.